      *      *                   *     *                          *
      **     *                   **   **                          *
      * *    *             *     * * * *          *          *    *
      *  *   *   *****  *******  *  *  *   *****  ******  ******* ******
      *   *  *  *     *    *     *     *  *     * *     *    *    *     *
      *    * *  *******    *     *     *  *     * *     *    *    *     *
      *     **  *          *     *     *  *     * *     *    *    *     *
      *      *   ******    *     *     *   *****  *     *    *    *     *
      *                                                                 *
      *         The monthly guide to BITNET servers and services        *
      *                                                                 *
      *  Volume 1  Number 9                                 March 1987  *
      *                                                                 *
       *****************************************************************
      *                                                                 *
      *  Editor:                          Chris Condon  CONDON@YALEVMX  *
      *  Assistant Editor:                Steve Sutter  SUTTER@YALEVMX  *
      *  NetMonth Staff Supervisor:       Gary Moss       MOSS@YALEVMX  *
      *                                                                 *
       *****************************************************************
      *                                                                 *
      *        File queue?  What file queue?  I don't see any...        *
      *                                                                 *
      *                                                                 *
      *                                                                 *
      *                                                                 *
      *                                                                 *
      *                                                                 *
      *                                                                 *
      *                                                                 *
      *                                                                 *
      *                                                                 *
      *                                                                 *
      *                                                                 *
      *                                                                 *
      *                      000000000 * 000000000                      *
      *                               0000>>>>>>>>>0000                 *
      *            00000(((((((((((((( * ))))))))))))))00000            *
      *         000((((((((((((((((((( * )))))))))))))))))))000         *
      *        00!!!!!!!!!!!!!!!!!!!!! * !!!!!!!!!!!!!!!!!!!!!00        *
      *        00((((((((((((((((((((( * )))))))))))))))))))))00        *
      *                                 00>>>>>>>>>>>>>>>>>>>00         *
      *                    000000000000000>>000000000000000             *
      *                          00((( * )))00                          *
      *                           0((( * )))0                           *
      *                           0((( * )))0                           *
      *        ''''4''''3''''2''''1''''0''''1''''2''''3''''4''''        *
      *                         00(((( * ))))00                         *
      *                      000(((((( * ))))))000                      *
      *                  0000000000000 * 0000000000000                  *
      *                              &(>&)>((>&>>)@&#&)&%(>@&<&<%(<#<<@ *
       *****************************************************************

1


   *************************************************************************
  * Contents                                                                *
  ***************************************************************************

  Bitnotes ................................................................ 1

  TAKE NOTE__________________________________________________________________

  Scuttlebut .............................................................. 1
  Netcon - Spring 1987 .................................................... 3
  Global Teachers' Network ................................................ 4

  FEATURES___________________________________________________________________

  Network Load ............................................................ 5
  To NIC or not to NIC? ................................................... 9
  NetMonth Reader Survey Results ......................................... 14

  SERVERS AND SERVICES_______________________________________________________

  A New File Server: SERVER@SUZEUS ....................................... 16
  A New Name Server: VMNAMES@UREGINA1 .................................... 18
  New Mailing Lists ...................................................... 20
  MACSERVE Moves to PUCC ................................................. 22

  DEPARTMENTS________________________________________________________________

  Feedback ............................................................... 23
  Policies ............................................................... 24

  NetMonth is a  network service  publication  distributed free  of charge to
  students and professionals in BITNET and other networks.  This magazine and
  it's  companion  file, BITNET SERVERS, are  the work  of the  Yale Computer
  Center  BITNET  Services  Library  (BITLIB) staff.  The  BITLIB  is a local
  online help  facility designed to  inform  Yale network  users  about  what
  services are available  to them  through BITNET, and  provide  instructions
  and  utilities  for their  proper use.  In publishing  NetMonth  the BITLIB
  staff  members hope  to share the  fruits of their  labor with institutions
  outside of Yale in  order to promote a productive  and enjoyable networking
  environment for everyone.

  BITNET SERVERS is BITNET's most  complete  and  up-to-date  list of servers
  and services.  It is sent to  NetMonth  subscribers at the same time as the
  magazine.  BITNET SERVERS is dependent  on your support to remain accurate.
  If you know of servers and  services  not  listed  in BITNET SERVERS, or of
  those listed in the file that  are no longer available, please  contact the
  NetMonth staff at BITLIB@YALEVMX.

  For information  on  subscribing  to NetMonth  and  BITNET SERVERS, see the
  "Policies" section on the last pages of this issue. Within "Policies" there
  are also instructions for  submitting  articles,  sending  Letters  to  the
  Editor, and printing this file.

  ------------------------------------------------------

  FuzzyBytes Electronic Publishing                      "Because We're Here."

1

                                                                       Page 1


   *************************************************************************
  * Bitnotes                                                        Issue 8 *
  ***************************************************************************

  Nobody, so I'm told,  is perfect.   This came as a shock to me,  but I have
  learned to  live with it.  My juggling of  School/Work/Friends/Netmonth has
  become (to say least) strained.   This has two major implications:

  1.  ALL of the glorious improvements that the Reader Survey inspired do not
  appear in  this issue of  NetMonth (or in  BITNET SERVERS).   They  will be
  appear slowly but surely in the next few issues, as I find the time to deal
  with them.  With this issue we have made  the initial  change of organizing
  the articles a bit more (see the Table of Contents for details).

  2.   I am unable to give you a proper Bitnotes this month.   However, there
  are some  issues which need  to be addressed,  but  I just haven't  found a
  moment to write about.   These are fairly complex,  and a LOT of debate has
  been keeping my mailbox full of interesting postings to LIAISON and LSTSRV-
  L.   I have chosen  the best of these to replace me  for this month.   And,
  rather than  contact all  of the  people involved  for permission,   I have
  simply removed any traces of names and network addresses.

  You will find all of this in the articles "Issue: Network Load" and "Issue:
  To NIC or not to NIC?"

  Before I go,  one last issue to address:   Please excuse our odd publishing
  schedule.    This magazine  goes  to the  "presses"  on the  second-to-last
  weekend of each month.  We have not been late.  Just strange.


                          Virtually,


                               Chris Condon@YaleVMX


   *************************************************************************
  * Scuttlebut                                                              *
  ***************************************************************************

  All the news that's fit to bit...

  * From  Zvika Bar-Deroma:   The LOOKUP  name servers at  RITVAXA/B/C/D have
  been consolidated into one server: INFO@RITVAXD.  For more information send
  the HELP command via interactive message  to the server.  (More information
  will  be published  in April  NetMonth,  or  as soon  as the  links are  up
  (whichever comes first). --Ed.)

1

                                                                       Page 2


  * From Niccolo' Avico:   "The LFCNET file server has been  shut down for an
  unlimited period of time;  this due  to  a rearranging of the files stored.
  The main reason for this is that this kind of server is no longer needed to
  the net.

  "LFCNET was  born in a pioneering  era,  which is now over:   no  LISTSERV,
  NETSERV  and   other  amazing  servers   were available then.   The network
  load was also lower, and a file server like this was able to survive.   Now
  this is no longer the case.  I can understand this.

  "Moreover I already planned to definitively  close LFCNET because of  it is
  time   consuming for   my own   life.   Because of this  there remains  the
  possibility of permanent shutdown."

  * From  John Voigt: "TCSSERVE  is being discontinued  in favor of  the file
  service facilities on Eric Thomas' LISTSERV.   Most of the files previously
  available on TCSSERVE  are now available from LISTSERV.   To  get a current
  filelist of what was moved one of the following commands should be used:

             "INDEX TCSSERVE" or "GET TCSSERVE FILELIST"

  "The main reason for this change is the additional  capabilities offered by
  the LISTSERV file server.   It will  respond to mail,  messages,  notes and
  files.   TCSSERVE only responded to interactive messages,  something that a
  very large part  of the network was  incapable of sending.   We  regret any
  inconvenience these changes  cause.   Our desire  is  to  provide the  best
  possible service  to the BITNET  community and  we feel these  changes will
  better serve the needs of most BITNET users.

  "We have also implemented a local LISTSERV command to provide NAME service.
  The command is $WHOIS  and will return E-mail address for  most of the user
  at  Tulane University.    To  use this  service simply  send  a command  to
  LISTSERV of the form: "$WHOIS userid/last_name".  Note that some users have
  several accounts and all will be  displayed.   I would appreciate comments,
  complaints and problems be reported to me."

  TCSSERVE processed  over 30,000  commands
  16,743 files  were sent  to 3,861 users at 389 different nodes.

  *  From Peter  Jaspers-Fayer:    "As  of Mar  1st,   the  old and  creaking
  SERVER@UOGUELPH will no longer be running.   The project was fun once,  but
  politics have so soured the whole concept here that I haven't touched it in
  many months.  I'm putting it out of it's misery."

  * New  list servers/file servers:  LISTSERV@IRISHVM  and LISTSERV@BYUADMIN.
  Thanks to Nick Laflamme and Rocky Waters for this information.

  *  New   NETSERV  file  servers:   NETSERV@NORUNIT,    NETSERV@TCSVM,   and
  NETSERV@MARIST.

1

                                                                       Page 3


   *************************************************************************
  * NetCon Spring '87                                                       *
  ***************************************************************************

  NETCON SPRING '87   A chance to meet fellow Bitnetters and Relayers!

  WHEN:               May 22-25, 1987

  WHERE:              New Orleans, LA

  REGISTRATION INFO:  $10 fee due April 24, 1987
                      (Make checks payable to Jim Harmening)

    Send to:          Jim Harmening
                      2033 W. 108th Place
                      Chicago, IL 60643

  HOTEL INFO:         New Orleans Marriott
                      555 Canal Street
                      New Orleans, LA 70140
                      504/581-1000

  HOTEL COST:   $49.95 for 3 nights,  4 people per room,  payable  to the the
  hotel upon arrival.   To guarantee for late  arrival (after 6 p.m.), send a
  deposit to the hotel after May 11, 1987.

  RESERVATIONS:   Send mail to Charlene Charette, GB0CBGS@TCSVM, BY APRIL 24,
  1987,  TO RESERVE A ROOM.   Include  your name and rooming preference.   In
  addition,   between May  15-21,   1987,  send  mail  to Charlene  Charette,
  GB0CBGS@TCSVM, to confirm (or cancel) your hotel reservations.

  NETCON T-SHIRTS:  Send mail to Jeff Robinson, IP60583@PORTLAND, if you want
  to purchase a Netcon T-shirt.

  ADDITIONAL INFO:   For additional information, signon to the Netcon mailing
  list, NETCON-L@NCSUVM, or send a note to Scott Campbell, SCOTT@UTORONTO, or
  Paul Ribeiro, ACPS2681@RYERSON.


                            TENTATIVE AGENDA

  FRIDAY, MAY 22, 1987

     3:00 or later      Checkin at Marriott Hotel
     8:00 p.m.          Welcome and greetings party
    10:00 p.m.          Night on the town

1

                                                                       Page 4


  SATURDAY, MAY 23, 1987

    10:30 a.m.          Seminar--Past and Future of Bitnet
    11:30 a.m.          Seminar--Past and Future of Relay
    12:30 p.m.          Lunch and site seeing (on your own)
     7:00 p.m.          Dinner as a group
     after dinner       Night on the town--French Quarter

  SUNDAY, MAY 24, 1987

    Whenever            Breakfast/Brunch
                        Whatever:  tours, zoo, paddle boats, street cars

  MONDAY, MAY 25, 1987

    Whenever            Goodbyes and departure


   *************************************************************************
  * Global Teachers' Network                                                *
  ***************************************************************************

  by Glen Turnbull                                               CEK4@UBCMTSG
  and Jeremy Meharg                                                  NEG8@SFU

  To:  All Educators of Children Throughout the World

  Those of you who  are reading this message are well aware  of the fact that
  this,  our  planet is  growing increasingly  smaller by  the day.   Current
  technological  advancements  in  telecommunications   and  electronic  mail
  provide the  capabilities for  Global Communications  never before  dreamed
  about.

  With these  new open channels of  communication comes the ability  to learn
  more  about others  and  the existing  diversification  of cultures.   This
  knowledge could lead to an increased awareness and clearer understanding of
  people throughout  the world  and encourage  the acceptance  of others  and
  eventual Global Peace.

  It is with  the purpose of promoting  these ideals in ALL  children that we
  wish to encourage the development of  a Global Teachers' Network.   We wish
  to offer our location (Vancouver, Canada:EXPO-86)  as a focal point for the
  GTN.  Using whatever Network system your  country has,  we request that you
  pass this message of hope along to others who are connected to your system.
  If you  are sincerely interested  in becoming  a participant in  the Global
  Teachers' Network,   send your name  and telecommunications address  to our
  location.  We  will confirm  your involvement  in the  GTN and  discussions
  should start soon.

1

                                                                       Page 5


   *************************************************************************
  * Issue:  Network Load                                                    *
  ***************************************************************************

  From the LIAISON and LSTSRV-L mailing lists:  Something to think about.

  ===========================================================================

  This notice is a follow-up to one that I posted in December.  The situation
  now is even worse than it was then.   As I mentioned then,  we began seeing
  constant queues  on the line to  OHSTVMA as soon  as Version 2 of  RSCS was
  installed.   That may not be the ultimate cause but that is exactly when we
  began having the queues.   Over the holidays, the traffic diminished enough
  to allow the queue to clear out.   The  situation now is that we have files
  queued for the line that arrived as long ago as Feb 2.   In fact,   we have
  60 files queued that arrived the first week of Feb., 169 files that arrived
  the 2nd week,  152 the third week,  and 166 files this week.   Several days
  ago,  I  ordered the  queue so that  all routing tables  from the  first or
  second  week  were finally  sent.    The  traffic  is slowly  but  steadily
  increasing.   A significant change is required to handle it.   Installation
  of modems running  faster than 9600 would certainly help.    A Reduction in
  the number of requests to servers around the network would help.  Running a
  RELAY at PSUVM might  help.   Running V2RSCS at PSUVM might  help.   A line
  from CUNYVM to another western or  mid-western node would help.   These and
  other changes  can be made to  help alleviate the situation.    Until then,
  network users must expect and tolerate some very long delays.

  ===========================================================================

  KNET-L subscribers  on the  TAMVM1 LISTSERV are  missing some  letters that
  were submitted at the DB0TUI11 peer of this list.   They are all waiting at
  PSUVM to  be transmitted to  OHSTVMA where  there is some  terrible problem
  with files of any significant size getting through.  I understand that some
  files are weeks old.

  ===========================================================================

  If everyone would shut their servers off  for the weekend,  we might,  just
  might mind you, approach some sanity!

  PSUVM-OHSTVMA queue always >1000 (file from 2/2 still there!)

  BITNIC-EARNET queue > 2000 all this week (except one morning it was 1850)

  CUNYVM-PSUVM always 750-1000 files

  The major culprit by far is the KERMit  server at CUVMA,  but there is alot
  of other duplicate junk file traffic as well!!!!

1

                                                                       Page 6


  ===========================================================================

  We can shut down our servers and  probably the queues will slowly decrease,
  but after a sufficient period  of time this will happen again.   To me it's
  obvious we must make some structural changes  in the method of distributing
  files. For example:

  BITNIC-EARNET queue > 2000 all this week (except one morning it was 1850)

  I cannot   understand why  the  BITNIC  LISTSERV  is  not peer-linked   for
  *every* list to   an EARN server (a   server in EARNET  would  be idoneous,
  but  we don't have  one at  present,  so perhaps CEARN   could do the job).
  I've  been  taking a look quite  regularly at the BITNIC-EARNET  queue this
  week and  most of  time the 255  first files  are  mail from  listserv  for
  several lists. Until  we get that fixed, european users may want to help by
  signing off from the BITNIC LISTSERV and subscribing to one of the european
  redistribution lists.

  ===========================================================================

  I have  talked to  Brian Nelson at  Toledo about  KERMSRV @  UOFT02 getting
  smarter (he was going  to relay this idea to CUVMA).   He was in agreement.
  Here are my suggestions:

  Set up a warning period for KERMSRV requests:

  If requests come  in from the "wrong"  side of the OSU/PSU  link,  tell the
  requestor that  he should use the  other kermsrv.   (then either  honor the
  request  with warning  of his  regional server  or forward  the request  to
  correct server and tell user what's going on...)

  Then plan for regional service areas:

  KERMSRV @ UOFT02 for west of OSU-PSU
  KERMSRV @ CUVMA  for east of OSU-PSU

  and have  each server  respond with  a file-being-sent  or use-other-server
  msg.

  I realize  the "what if  one server is down"  situation needs to  be solved
  too.  But this should also be part of the region server solution.

  ===========================================================================

  Considering the back log that has been occuring at the PSUVM site,  and any
  other sites...I have  noticed exceptionally large files  being transmitted.
  A super example  was one sitting in the  queue for CUNYVM at  PSUVM (and is

1

                                                                       Page 7


  most likely still there) that was a mere 94,425 records.   (this translates
  into at  least 7M  bytes -  a tad over  the max  file size  recommended for
  BITNET usage.)  I think becoming a bit more rigid about file transfer would
  assist a bit in relieving the backlog and network load problems.

  Now, the other problem is to come up with a good way of monitoring the file
  sizes without having to keep a human eye on it ...  is the author of NETMON
  still around...maybe  an option to NETMON  to monitor the file  sizes every
  minute or two and if file is large...place  it on hold and notify the local
  staff to make a decision to flush the file.  Again,  this attitude may be a
  bit rigid - but we have to start somewhere?? yes?

  ===========================================================================

  I was always somewhat suspicious of NETMON (perhaps falsely so) because, as
  I understood  it to work,   it queries link  status over the  whole network
  periodically (10 minute intervals?) and parsed the returned output.  If you
  check every link, that is 1700+ queries going out and somewhere in the same
  neighborhood of messages returned.   That is one heck of a message load and
  will freeze file transfers  for a significant period of time.    If you rig
  NETMON (et al) to query another node's queues,  recall that you can get 100
  messages back (if 100+ files are queued).  Kaboom.

  Another issue everyone is bouncing around is that of relocating servers and
  so forth to 'this side or the other'  of 'this or that bottleneck'.   As of
  6:00 AM EST  this morning (when queues  *should* be *empty* and  all normal
  people in the US should be asleep) the following queues were left:

       PSUVM  -> OHSTVMA   469 files;  OHSTVMA -> PSUVM  zero.
       CUNYVM -> PSUVM     887 files;    PSUVM -> CUNYVM zero.
       BITNIC -> EARNET   1660 files;   EARNET -> BITNIC 10 files.

  Bob Fowles observed that some 30% of his queue was from Bitnic servers.   I
  would suspect  a sizeable portion  of the  queues were also  accountable to
  Kermit and/or LISTSERV as well.   Suggestions have been kicked around about
  moving certain  servers to PSUVM and/or  OHSTVMA,  etc.   In any  case,  an
  attempt  is made  to subdivide  the 'hub'  into other  segments,  and  then
  placing servers on the corresponding hub.

  It may sound ludicrous at first,  but the best solution would be to put the
  server for  a given  segment as far  out in  left field as  you can  find a
  volunteer (and you usually find volunteers out  on the ends).   As you will
  note from the queue sizes above,  the bottleneck is OUTBOUND from the hubs;
  there is little  or no backlog INBOUND.    By placing servers on  some end-
  node,  the traffic is  now INBOUND,  with the bulk of  the traffic going on
  links which are normally relatively idle.  As the remaining copies approach
  the crowded hubs,  the number of copies  will decrease;  with the last copy
  going to the hub node itself.

1

                                                                       Page 8


  There is still a considerable amount of  bandwidth left in the network,  it
  just happens to be  going in the 'wrong' direction.   We  could,  with some
  effort, take advantage of these available bitbuckets.

  ===========================================================================

  It is all very  well to explain why BITNIC's servers *had*  to be shut down
  to  alleviate the  backlog at  critical  network links,   but that  doesn't
  address the issue I raised, namely, that LISTSERV, in particular,  need not
  place an appreciable load on any of the critical links.  Surely, in view of
  the evident crisis, this would be a very propitious time to link the BITNIC
  LISTSERV with the many available peer servers throughout the network.   The
  advantages are obvious:

  1. BITNIC could immediately shift subscribers to the peer servers.

  2. Mail to one of the BITNIC lists would generate only *one* copy over each
  of the critical links.

  3. Mail sent originally to one of the peer servers (i.e., mail other than a
  reply  to a  previous  message)  would  already  have  been distributed  to
  subscribers downward  of the corresponding critical  link to BITNIC  and so
  would not generate any return traffic at all.

  4. BITNIC could legitimately delegate the responsibility for archiving list
  traffic to one  or more of the  peer servers,  thereby cutting  off another
  source of load on the critical links, namely, file requests.

  5.  BITNIC could automatically assign new subscribers to their nearest peer
  server, thereby avoiding the necessity of close human scrutiny.

  6.  BITNIC could even legitimately restrict  the file server aspects of its
  LISTSERV.   For example, the usual memo files describing all the aspects of
  LISTSERV could be  replaced by short messages listing the  peer servers and
  suggesting that requests be referred to the nearest one.

  ===========================================================================

  If NICSERVE  saves large file  requests until after  midnight when most  of
  my  users have  logged off  and  gone home  I  have no  problem with  using
  DISTRIBUTE to send the files.   Especially  when the alternative  is for me
  to have  to wait 3 weeks and still not  get my file,  or to have to receive
  and then send 10 copies to people  beyond me in  the network.   I'd just as
  soon receive one  copy and generate the others needed.

  NICSERVE  needs to   have a  size  threshold beyond  which  files  are sent
  via distribute.   Small   files  can be  sent  now,   big   ones  should be
  held  and DISTRIBUTED  after midnight  to  everyone  who requested  them in
  the past  24 hours.

1

                                                                       Page 9


   *************************************************************************
  * Issue:  To NIC, or not to NIC?                                          *
  ***************************************************************************

  From the LIAISON mailing list:  Something else to think about.

  ===========================================================================

  In reading  mail from this and  other lists I  there seems to be  a general
  pattern of people asking  for software for a Vax or  Unix machine,  and the
  responses are always, "sorry, it only runs on IBM". I know IBM helped start
  Bitnet, but as I scan the nodes list,  I see a tremendous number of non-IBM
  machines, yet I have noticed no real effort by BITNIC to bring these people
  "into the  fold" other  than a simple  connection to  Bitnet.  Are  all the
  people at BITNIC IBM blue-bloods?  With so many other systems out there,  I
  should think the  people in power would  make a stronger effort  to convert
  software,  but I haven't  even heard any verbal efforts.  And  with all the
  talk of  heavy Bitnet traffic  and delays,   many of the  proposed software
  solutions (more servers, more local distribution of files, etc. ) cannot be
  effective because at least half of the machines out there cannot run it.

  Even if they wish to remain loyal to  IBM,  I bring to their attention that
  IBM,  along with many other firms,   has publicly expressed support for the
  proposed POSIX (UNIX)  standard,  so there is at least one non-VM operating
  system that we all can support without offending anyone.  Anyway, if all of
  the rest of us gang up on the IBM people, maybe something might get done.

  ===========================================================================

  I think you need to get the horse and the cart in the right order.   First,
  BITNIC has *NO* money for development.  Most of the network tools in use on
  BITNET's  IBM systems  were written  by  volunteers.   In  the past,   some
  software was  developed by BITDOC,   not BITNIC,   under a grant  from IBM.
  Perhaps DEC would like to make a  million dollar grant to BITNET for better
  support of VAXen  on BITNET?   On bad days  I am prone to  think that maybe
  getting BITNIC was one of the *WORST* things to happen to BITNET.

  It seems to have stifled our volunteer spirit.  Ã•sorry, but the libertarian
  in me just  can't help noting that this  is much like people  who feel that
  since we  have government the way  to solve all  problems is to pass  a law
  saying that someone else should solve the  problem.Ã¥ Certainly it is in all

  our interest to have BITNET working equally well for all kinds of computers
  but  the non-IBM  part of  the net  is I  think going  to accept  a lot  of
  responsibility for  making that happen because  you have the most  to gain.
  The NIC's job  is to coordinate and  facilitate,  and I'm sure  that to the
  extent that  they are made  aware of non-IBM tools  out there they  will do
  their best to see that those who need to know about them can find out about
  them.  If they don't, then fault them.

1

                                                                      Page 10


  ===========================================================================

  Also, VM systems were on the net first (with network-inadequate IBM vanilla
  code)  long enough for people to get frustrated enough with %#$^&% IBM NOTE
  etc to write something better.  It's only a matter of time before there are
  MAILERs and so  on for VMS and UN*X  too.  But you VAX folks  have to write
  them!

  Speaking for myself, anyway, I don't think the IBMers on the net are in any
  way prejudiced  against VAXers* -  we'll be glad  to support the  effort to
  translate/analogize VM tools  to whatever you want  to run them on.   If it
  helps the network, it helps all of us.

  ===========================================================================

  Recent discussions on  NODMGT-L have discussed this  touchy issue somewhat.
  I believe the consensus has been, yes,  we need equivalent tools for other,
  non-IBM systems.   However, under the new charter recently adopted,  BITNIC
  has no money for development.   The consensus from that has been, ok,  it's
  up to  the VAX sites  or the UNIX  sites or  whomever;  we'll give  as much
  support as we can in explaining algorhythms or data structures,  but no one
  is going to do it for them.

  I disagree with your contention that VM-based tools will not be adequate to
  relieve  the network  load.   The  network  backbone,  that  which is  most
  overloaded, remains VM-based.   We therefore can put VM-based servers where
  they are most needed and where they can greatly reduce the load.   I am not
  suggesting that non-VM  versions should not be developed,  but  I am saying
  that doing just VM initially will in fact be a great help.

  While I understand  your frustrations with the current  situation,  I think
  your grievances are being addressed.

  ===========================================================================

  First,  it is nice to known that there are still a few libertarians around.
  I did  not what  to imply  that money  should immediately  be spent  on new
  programs, but I noticed that we non-IBM users tend to be ignored a lot.  It
  would be nice  to hear a word  of encouragement or some  recognition of our
  existence.  Not only is there a gulf between DEC and IBM, but the same gulf
  often exists between the two user groups  as well (also include Unix people
  in there own world).

  As to the spirit of volunteering,  I also agree it is reduced.  I am just a
  lowly  programmer  who is  confused  by  tangled  mazes of  authority  like
  Executive committees and EDUCOM and working groups. Any bureaucracy that is
  large  enough to  organize conventions  with  workshops,  planning  groups,

1

                                                                      Page 11


  elections,   etc.   frightens me  (wouldn't  a  few mail  messages  between
  interested users have sufficed,  and then  let everyone on Bitnet who wants
  to send in a vote?).  When there are powerful groups around,  an individual
  had better not try anything alone  without getting approval first,  or risk
  the wrath of someone above,  and I  prefer to avoid such politics.  Anyway,
  perhaps a few people will keep it in  mind at that convention that there is
  a need for non-ibm  software.  (When I buy my Cray 4 with  Unix,  I want to
  have LISTSERVS and NETSERVS and RELAY too! ;-) ).

  ===========================================================================

  Surely,  you  aren't suggesting that  BITNIC should purchase  new computers
  and/or operating systems  and hire a staff of programmers  to develop fancy
  software for all the non-VM people on BITNET!   Most of the whizzy packages
  we see were  developed more or less  spontaneously -- i.e.,  if  you really
  want a  specific piece  of software,  you  must write  it yourself  or find
  someone else who wants it sooner than you do.

  ===========================================================================

  This lack of support from BITNIC does not only concern nonIBM systems.   We
  are an MVS site (IBM 3033) and cannot get ANY support from BITNIC.  It took
  a personal meeting with Michael and Judy to get on the LIAISON mailing list
  last time.  It took a phone call from myself and the director at Cornell to
  get some information in the BITNET tables corrected.

  Judy,  Scott,  and company complain that  they are vastly overworked.  They
  must be, since many database items have not been updated in over a year.  I
  have been finding out most of my  information from other MVS sites who have
  gone through similar problems in trying  to get information.   I have found
  more helpful and knowledgeable support from  the ARPA and CSNET information
  centers and the various gateway masters than BITNIC.

  ===========================================================================

  I have basically two questions:

  1)  Have alternate  sources of funding for BITNET  been investigated?   For
  example, educational type grants, other companies (DEC, AMDAHL).  Money and
  the fee structure seem to be the hook most user's are objecting to.


  2) Where,  EXACTLY,  does the money go?   Various nodes are (or seem to be)
  volunteering services  to replace BITNIC  at considerably lower  dollar and
  manpower costs.  My understanding of BITNET is that a great deal of work is
  done by member  institutions on a "round-tuit"  VOLUNTEER basis,  including
  such important task as distributing routing tables.

1

                                                                      Page 12


  Point  one has  already been  decided.    Money hasn't  been allocated  for
  development,  according to what I have read.   Money apparently hasn't been
  allocated for info services either.  Where did/does the money go?

  ===========================================================================

  Those are  good questions...   questions that  a number of us  asked,  even
  fought over,   before the  charter was  "approved."  You  are not  alone in
  feeling that adequate answers have not yet been given.

  Let's back off,  give them a few months to get themselves organized if they
  can, and then "give it to 'em Harry" if need be.  After all, if indeed they
  are able to incorporate,  and the organization doesn't leak like a sieve in
  court, then we,  as purchasers and subscribers,  have a solid position from
  which to demand change.   And frankly, if this is the way that we can get a
  reliable,   contracted  level of  service  that  is  better than  and  more
  consistent than the voluntary (and very worthy!)  efforts that we now have,
  born of necessity,  then maybe this is not  such a bad idea after all,  eh?
  We shall see.  We shall see.

  ===========================================================================

  The most critical fault  that has been made to date by  the BITNIC staff is
  to address themselves only to the upper-level campus administration.   They
  were  interested in  securing money  and recognition  for themselves,   and
  decided that this was where the money was.    They saw no need to to invite
  the favor of the user community.   In fact, they seem to be quite afraid of
  what the user community might have to  say against them -- and therefore do
  not want to listen.  They seem to believe that their jobs depend on it.

  But the opposite is  true.   If you want to reach  the node administrators,
  you must  do so through  the users.   You  must do  that by serving  in the
  classic  coordinating and  facilitating role  of true  management,  and  by
  serving a perceptibly  beneficial role.   The computer  center personnel in
  particular,  the   "Techhies," will be  called  upon  to be advisors to the
  upper managers,  who of course will not spend money without knowing whether
  the proposal makes good business sense.

  The  "American Revolution"  began when  certain users  realized that  their
  needs were not being  met in the EDUCOM proposal,  and  assumed that BITNIC
  would be favorable to a better approach.   It ended, I believe,  when those
  same people realized that BITNIC did not want to know.  That was no victory
  for BITNIC,  because  a lot of ears  were sealed up as  these people simply
  went on the offensive.  BITNIC has a lot of explaining to do now.

  We don't need  an ivory tower in the  middle of BITNET.   We  need a better
  BITNET.  If BITNIC wants to help do that, then welcome aboard.   Otherwise,
  good riddance.

1

                                                                      Page 13


  ===========================================================================

  I am glad to hear that at least the talk from   Mr. D'Amore has improved by
  a quantum leap.  At SIGUCCS in Montreal,  I  had a chance to talk with both
  Michael  D'Amore and  Judith  Molka.  At  that point  in  time,  they  both
  maintained that  BITNIC was  doing wonderful  things,  and  that everyone's
  problems  were due  to not  following  the proper  procedure for  obtaining
  information.  In the  session that they presented,  they received  a lot of
  hostile comments  for their  stance.  Some  of us  at that  point tried  to
  maintain that it was impossible for them  to know all of the possible types
  of connections to BITNET,  and that they should possibly refer some queries
  to the network.  Both  of them asked the group if the  group was willing to
  field questions, and we responded yes.

  In the months that have followed, there has been no change in the stance of
  BITNIC. When the ARPA-BITNET gateway was restricted, BITNIC didn't respond.
  I was not at SHARE,  but from the comments that you are making,  it doesn't
  seem that  a good  solution to  the traffic  problem was  reached.  I  also
  haven't heard any progress in regard  to running TCP/IP across the network,
  which would allow for some better routing protocols (if the hardware was in
  place).

  ===========================================================================

  I will agree  that it is somewhat disheartening that  BITNIC cannot provide
  all the services that it once provided and/or we think it ought to.   There
  are,  however,  several on this list that  could possibly help out with the
  volunteer effort to keep up some of these things.  If BITNIC cannot help us
  the way we need,  then maybe we can help ourselves.   What we really need I
  think  right now  though is  someone to  volunteer to  help coordinate  the
  volunteers...collect all  the "we  wants" and  all the  "I will  helps" and
  match them or something.   In other words,   couldn't we have just a little
  organization of the volunteers?





                                      *
                                  *  ***  *
                               *   *  *  *   *
                             *    *   *   *    *
                            *    *    *    *    *
                            *    *    *    *    *
                             *    *   *   *    *
                               *   *  *  *   *
                                  *  ***  *
                                      *

1

                                                                      Page 14


   *************************************************************************
  * The NetMonth Reader Survey RESULTS                                      *
  ***************************************************************************

  1.  How long have you been reading NetMonth?

      20%  a. 1-2 months
      17%  b. 3-4 months
       9%  c. 5-8 months
      54%  d. I was a Bitlist reader

  2.  Are you a(n):

      23%  a. undergraduate student
      14%  b. graduate student
      44%  c. computer center staff
      25%  d. educator (doctor, professor, teacher, etc.)
      11%  e. other

  3.  How old are you?

      31%  a. 18-25
      33%  b. 26-35
      30%  c. 36-50
       5%  d. 51+
       3%  e. none of your business!

  4.  Are you:

      97%  a. male
       3%  b. female
                         Ã•Ha! -- Assistant Ed.Ã¥

                         Ã•One wonders if there is any connection between
                         3% who are female and the 3% who wouldn't admit
                         their age... -- Ed.Ã¥

  5.  Do you read any electronic magazines other than NetMonth?

      51%  a. yes
      49%  b. no

  6.  Do you subscribe to any digests/mailing lists?

      65%  a. yes
      25%  b. no

1

                                                                      Page 15


  7.  How often do you sign on to RELAY?

       6%  a. almost every day
      18%  b. a few times a week
      14%  c. a few times a month
      21%  d. not more than once a month
      40%  e. never

  8.  Have you ever used a file server before?

      93%  a. yes
       7%  b. no

           Ã•Mostly NETSERV, CSNEWS, and LISTSERV.  -- Ed.Ã¥

  9.  Have you registered yourself on a name server?

      51%  a. yes
      49%  b. no

           Ã•Mostly NETSERV and CSNEWS.  -- Ed.Ã¥

  10. What operating system is your mainframe running?

      71%  VM/SP, VM/CMS
      17%  VAX/VMS
       6%  MVS/XA
       1%  MTS
       1%  TMO

  Results  from the second half  of the  survey (your  opinions on  NetMonth)
  will be  published  in the  next  issue.  The  results of  essay questions,
  as some  of you  know,  are difficult  to quantify. However, we have gotten
  several  distinct  messages  about what  you would  like to  see and  where
  the magazine  should go  in future  issues.  Other conclusions  are hard to
  draw since  most of  you disagree on  key points, such as how technical the
  articles should be.  More in April.




  *****     *****     *****     *****     *****     *****     *****     *****
       *****     *****     *****     *****     *****     *****     *****
  *****     *****     *****     *****     *****     *****     *****     *****
       *****     *****     *****     *****     *****     *****     *****
  *****     *****     *****     *****     *****     *****     *****     *****
       *****     *****     *****     *****     *****     *****     *****
  *****     *****     *****     *****     *****     *****     *****     *****
       *****     *****     *****     *****     *****     *****     *****

1

                                                                      Page 16


   *************************************************************************
  * A New File Server:  SERVER@SUZEUS                                       *
  ***************************************************************************

  by Tony Dahbura                                                 TONY@SUZEUS

  The SERVER Virtual  Machine at SUZEUS (Syracuse University)   will send you
  any file  it has  access to  excluding its  internal system  files.   Valid
  commands are:

     LIST 
     LIST userid cuu password
     SEND fname ftype 
     SEND fname ftype userid cuu password
     NODE bitnet node name
     WEATHER city
     ID

  You should send commands to SERVER@SUZEUS via interactive message,  such as
  TELL, MSG or SEND.


  Command explanations:

  LIST    will send  a list of  the server's  files.   If  the optional
   is specified i.e.  TELL SERVER AT SUZEUS LIST D, and the extra disks
  are available (based on  free disk space at SUZEUS)  then  a listing of the
  files on the specified disk will be sent.  Default mode is A.

  LIST  userid cuu  password   will  cause the  server  to  try to  link  the
  specified account's disk using the password  supplied.   The link will be a
  R/O only link.   Thus all files that are of type A0 will not be included in
  the listing.   This feature is mainly for SUZEUS users when at other nodes.
  If the disk is a public disk (no password needed to link) then don't supply
  a password.

  HELP  will cause the  server to transmit its help file  (this document)  to
  you.

  SEND fname  ftype    will cause  the selected  package to  be sent  -
  packages are a list  of all files associated with a  certain program.   For
  example requesting the PLIX package would  send all the required plix files
  with one easy command.   To request the PLIX package issue the send command
  as SEND PLIX.   If the package were on  a minidisk at mode D then you would
  have to spell the entire name out i.e.  SEND PLIX PACKAGE D.   NOTE: If the
  requested file is over 30 blocks in  size and SUZEUS system time is between
  7:30 am and 8:30 pm  the file will not be sent.   You will  be told if this
  happens and your request will be queued and handled after prime time.

1

                                                                      Page 17


  SEND fname ftype userid cuu password  will cause the server to try and link
  the specified disk and send the file.   See the LIST command for details on
  linking.

  NODE  will take  any valid bitnet node  name (* accepted as  wildcard)  and
  will return the name of the node.  If the wildcard forces more than 4 nodes
  to match then only the first four will be sent.

  WEATHER will give you the latest up to date weather forecast for most major
  US cities.    Passing a ?  or  nothing will result  in a list of  the valid
  cities.  This feature is provided courtesy of Niagara Mohawk Electric.

  ID  will send an identifying message back about the server.


  Notes:

  Please be patient with the server as it is running on a trial basis.

  Please do not cause network overloading by trying to download every file on
  the server.

  The LIST files are sent in EXEC format.    You can edit the file and remove
  the files  you don't  want and  using the  following REXX  program you  can
  request the server to send the remaining files.


   *************************************************************************
  *                                                                         *
  *                                                                         *
  *             /*  GET FILES FROM SUZEUS */                                *
  *             'EXECIO * DISKR CMS EXEC (FINIS'                            *
  *             DO I = 1 TO QUEUED()                                        *
  *                  PULL . . FNAME FTYPE .                                 *
  *                  'TELL SERVER AT SUZEUS SEND 'FNAME' 'FTYPE             *
  *             END                                                         *
  *                                                                         *
  *                                                                         *
   *************************************************************************


  Finally - If you have a program/exec  you think others might find useful or
  helpful then send it to the SERVER at SUZEUS.

  Please  address  suggestions/questions/complaints etc.   to  Tony  Dahbura,
  TONY@SUZEUS.


1

                                                                      Page 18


   *************************************************************************
  * A New Name Server: VMNAMES@UREGINA1                                     *
  ***************************************************************************

  This name server knows  of any userid on Regina's VM  system who has signed
  up to the name  server via the ADD command.   In addition it provides a few
  network services that are described below.

  Users can send commands to this server in many different ways:

  1) INTERACTIVE MESSAGES (valid only for Bitnet users):

     TELL VMNAMES at UREGINA1 command
     SMSG rscsid MSG UREGINA1 VMNAMES command
     SEND VMNAMES@UREGINA1 command

  These commands are only valid for Bitnet users who have the ability to send
  interactive  messages.    Responses sent  back  from  VMNAMES will  be  via
  interactive messages.


  2) FILES (valid only for Bitnet users):

  VMNAMES will also respond to a file that arrives in either CMS PUNCH format
  (with  or without  a header  - both  are accepted)   or via  the CMS  PRINT
  command.   The file should contain only one  line and it should contain the
  command that you wish to execute.

  VMNAMES will send  its responses back as  a file based upon  the format and
  file class of the received file.

  Files that  arrive in any  other format  (i.e.  Cornell's Card,   Disk Dump
  format,   etc.)  will  result in  this help  file  being sent  back to  the
  originator.


  3) MAIL (valid for all Internet users):

  VMNAMES will accept standard Bitnet mail files as commands.   The mail must
  arrive with a  filetype of 'MAIL' and  a class='M' in order  for VMNAMES to
  recognize the file as  being mail.   This is the format  of Bitnet standard
  mail files.  In addition, the mail must conform to Arpanet standard RFC822.
  If your  'From:' field does not  supply a fully qualified  network address,
  then VMNAMES will not be able to send mail back to you.

     Example:
     Valid address:   From: xyzzy@mitre-bedford.arpa
     Invalid address: From: xyzzy@mitre-bedford

1

                                                                      Page 19


  The first  non-blank line  after the mail  header will  be accepted  as the
  VMNAMES command.

     Address your mail to:
     VMNAMES%UREGINA1.BITNET@WISCVM.ARPA
     if you are located on another network other than Bitnet.


  4) IBM NOTE (valid for Bitnet users):

  VMNAMES will  accept standard  IBM NOTE  format files.    It will  send its
  results back to you  as a file based upon the  information contained in the
  received file.


  COMMANDS:

     HELP
     WHOIS  ] 
     AUTOLOG vmuserid pswd
     ADD 
     DELETE


  HELP - returns this  file and will only be returned as either  a file or as
  mail.  HELP will not respond via interactive messages.

  WHOIS - will determine what the person's real name is behind the userid, or
  if lastname is given,  will return the  userid as associated with that last
  name.   Searching by  userid will return one person,   whereas searching by
  lastname may return many people (i.e. WHOIS COHEN)

  If a match is not found, a phonetic search will be performed to try to find
  a match.

  AUTOLOG - is only  valid via interactive messages or via  a file.   This is
  not a  valid command via  mail.   This  command will startup  the specified
  userid and in addition will place the user in 'GONE' mode.  If the user has
  customized his/her id  properly,  then remote commands can  be entered from
  anywhere in Bitnet for execution locally.

  Care should be taken when designing  your PROFILE EXEC.   Any commands that
  use the program stack should be nested with MAKEBUF/DROPBUF.   In addition,
  any commands  within your  PROFILE EXEC  that require  a response  from the
  terminal  (MAIL,   RDRLIST,  etc.)   should  be  bypassed when  running  in
  disconnect mode.

1

                                                                      Page 20


  ADD -  Adds the user along with the specified information to the names file
  used by VMNAMES.   A 'NULL' in any of  the fields except first name or last
  name results in that field being unlisted.

  DELETE  - Deletes  the user  from the  names  file used  by VMNAMES.    Any
  modifications to any of the information contained  in the names file may be
  accomplished by deleting yourself and then  adding self back into the names
  file.

  For further details or if you have questions, contact:

            Thollrob@URegina1    ( Robert Tholl  )
            Malachkm@URegina1    ( Ken M. Malach )
            Smidtshe@URegina1    ( Shelley Smidt )


   *************************************************************************
  * New Mailing Lists                                                       *
  ***************************************************************************

  ICECNET#@ANDREW.CMU.EDU

  ICEC,   the InterUniversity  Consortium for  Educational  Computing,  is  a
  consortium of  universities  and  colleges committed  to  developing  high-
  quality educational applications for advanced computing environments.

  ICECNET  has  been  the  newsletter of  ICEC  for  several  years.    Paper
  publication continues, but a copy of each issue of the newsletter will also
  be released about once a month via this mailing list.

  ICEC has  supported software  development at  member schools  and conducted
  activities for faculty  from member schools (e.g.   developers' conference,
  training  programs in  courseware development  for advanced  workstations).
  Other mechanisms  are evolving to  promote development of  good educational
  programs  for advanced,   graphics-intensive  workstations  and to  aid  in
  sharing these developments among interested parties.

  ICEC is therefore initiating an internet  mailing list (1)  for publication
  of information about ICEC,  (2)  communication among member schools related
  to internal business,  and (3)  as a forum for discussing issues related to
  the general objectives  of ICEC.   Examples of the third  category might be
  "what constitutes  high-quality courseware?",  "what Unix  workstations are
  best suited  to general educational use?",   "what mechanisms are  best for
  sharing educational developments using advanced technologies?", etc., etc.,
  etc.    Individuals,   both   from  member  schools  and   from  non-member
  organizations, are invited to contribute in this third area.

1

                                                                      Page 21


  All submissions for the monthly (paper) newsletter should be sent to:

     Patricia Clark,ICECNET editor  or
     Robert Cavalier, assistant director of ICEC 

  All requests to be added to or deleted from this list, problems, questions,
  etc., should be sent to ICECNET-REQUEST#@ANDREW.CMU.EDU.


  INFO-MODEMS@SIMTEL20.ARPA

  Info-Modems is a discussion group of special interest to modem users.   The
  list is gatewayed to/from Usenet newsgroup comp.dcom.modems.

  All requests to be added to or deleted from this list, problems, questions,
  etc., should be sent to Info-Modems-Request@SIMTEL20.ARPA.

  Coordinator: Keith Petersen 


  INFO-PRIME%FNS1@USC-ECL.ARPA

  Info-Prime is a mailing list for discussion of Prime computers.  Discussion
  on Primos,   Prime Information (PICK-like database/operating  system),  and
  Primix (Prime's unix) are all welcome.  There is no direct affiliation with
  Prime computer  corporation (Prime employees  are,  of course,   welcome to
  participate).

  Archives will be kept. To access them contact Info-Prime-Request.

  All requests to be added to or deleted from this list, problems, questions,
  etc., should be sent to Info-Prime-Request%Fns1@USC-ECL.ARPA

  Coordinator: Bob Larson 


  SIMULA@BITNIC

  A forum  for people interested in  SIMULA,  a language  for object-oriented
  programming and simulation; a member of the ALGOL family.  Topics may range
  from  hints  on  programming  techniques  to  information  about  available
  software (both compilers and programs),   questions and answers in general,
  etc.   In short,  anything that has to  do with SIMULA.   This group is not
  restricted  to any  specific  implementation of  SIMULA;   the exchange  of
  information between users of different implementations is encouraged.

1

                                                                      Page 22


  To subscribe to this list, send  the following  command to  LISTSERV@BITNIC
  via interactive message (for example, TELL, MSG, or SEND):

       SUBscribe SIMULA Your_Full_Name

  (where Your_Full_Name is your name).   If you cannot send messages, you can
  send the command as the first line of a mail message to LISTSERV.

  Coordinator: Per Lindberg 


   *************************************************************************
  * MACSERVE Moves to PUCC                                                  *
  ***************************************************************************

  From Bitnews March 9, 1987

  MACSERVE Moves To Princeton University

  MACSERVE@PUCC,   which  replaces  MACSERVE@BITNIC,   is  now  operating  at
  Princeton University.  MACSERVE@PUCC contains a current and complete set of
  archives.

  In the  past,  the MACSERVE  fileserver on the  BITNIC node was  updated by
  issuing an FTP to the SUMEX-AIM  ARPAnet node,  via borrowed 9600-baud line
  for TCP/IP.   When the line became unavailable, MACSERVE could no longer be
  updated at node BITNIC.

  MACSERVE receives interactive commands only.   To start using MACSERVE,  VM
  sites should issue the following:

          TELL MACSERVE AT PUCC HELP

  For VAX sites:

          SEND MACSERVE@PUCC HELP

  Users at other sites should contact a local user-services representative.





     *   *   *   *   *   *   *   *   *   *   *   *   *   *   *   *   *   *
    * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
   *   * * *   * * *   * * *   * * *   * * *   * * *   * * *   * * * * *   *
    * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
     *   *   *   *   *   *   *   *   *   *   *   *   *   *   *   *   *   *

1

                                                                      Page 23


   *************************************************************************
  * Feedback                                                                *
  ***************************************************************************

  Date: 9 March 1987, 11:28:50 EST
  From: Murphy A. Sewall                                       SEWALL@UCONNVM
  To:   Christopher M. Condon                                  BITLIB@YALEVMX

  Subj: For NetMonth letters

  Although I've known Bitnet was "there" for some time,  it wasn't until Fall
  '86 that I had any real need of  it.   Then in the process of communicating
  with a colleague at a distant university I began to "discover" (have handed
  to  me really)   bits and  pieces  about other  useful services  (COMSERVE,
  PSYCHNET, BITSERVE, etc.).  I just discovered NetMonth (and got the Feb '87
  from PSYCHNET which  is rather inefficient because that amounts  to send it
  back across the  links from which it came  in the first place --  it had to
  "pass through" Yale to get to me).

  Yes I would like to be added to the growing subscriber list.  Can I get the
  back issues  as it  appears there  are not  a really  large number  and the
  letters column indicates that there are some interesting articles in them?

  I do not  know much really about  how "mass mailings" on  Bitnet work.   If
  there are  a dozen or so  subscribers at a  single node,  is one  copy sent
  along the network and then "duplicated" at the receiving node?  Would it be
  more  efficient,  if  I could  talk the  local computer  center staff  into
  finding some disk space for recent issues  of NetMonth (then they could get
  one copy and the rest of us could just read it)?

  Is there  some handy source  of info for us  "late arrivals?"  I  find your
  BITNET SERVERS  file interesting  reading,  but  I not  entirely up  to the
  "jargon  density"  (I could  use  a  fuller  explanation of  NETSERVers  vs
  LISTSERVers for instance).

                               Murphy


  >>>  Our BITNET  USERHELP  file is  generally  helpful.    It explains  the
  differences between file servers, name servers, list servers,  relays,  and
  all  of those  other  wonderful services.    BITNET  SERVERS  will soon  be
  undergoing major  improvements,  where each  individual server  listed will
  have a  brief explanation  of what  kind of  files are  available,  special
  features, and how it will accept commands (mail, message, file).   USERHELP
  may be re-issued soon in a slightly  revised edition which will reflect the
  recent changes to LISTSERV.   (The last real changes were made in August of
  1986.  It's about time for an update).

1

                                                                      Page 24


  >>> You can get BITNET USERHELP from any NETSERV file server by sending the
  command SENDME BITNET USERHELP via interactive message or as the first line
  of a mail file.  For example:

      TELL NETSERV AT BITNIC SENDME BITNET USERHELP
      SEND NETSERV@BITNIC SENDME BITNET USERHELP
                                                        -- Ed.


   *************************************************************************
  * NetMonth Policies                                                       *
  ***************************************************************************

  Subscribing to NetMonth and BITNET SERVERS:  Send  a mail message with your
  name and network  address (userid@node)  to  BITLIB@YALEVMX  (Arpanet users
  send your mail to BITLIB%YALEVMX.BITNET@WISCVM.WISC.EDU).

  Letters to the Editor:  If  you have  questions  or  comments  about BITNET
  or  NetMonth  that  you  would  like  printed  here,  mail  your l etter to
  BITLIB@YALEVMX.  Make sure that you  specify  in  the "Subject:"  header or
  somewhere in the letter that it is for the  NetMonth  letters  column. This
  doesn't mean that your letter will be printed, but it helps.

  Article Submissions:  The  only requirements for NetMonth articles are that
  they be informative,  interesting, and  deal with  BITNET  services (or any
  other  good BITNET  related topics).  The  editor  will  inform  you of any
  changes to your writing and will submit them  for your  approval, deadlines
  permitting.  Send your articles to BITLIB@YALEVMX.

  Printing this file:  VM users can print this  file by  first  copying it to
  NETMONTH LISTING and  then printing  the new file.  This will  allow  page-
  breaks and other formatting to be understood by your printer.

  ---------------------------------------------------------------------------

  FuzzyBytes Electronic Publishing                      "Because We're Here."